home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.93-03-08 < prev    next >
Text File  |  1993-04-21  |  17KB  |  443 lines

  1.   
  2.       
  3.                     IETF STEERING GROUP (IESG)
  4.  
  5.                   REPORT FROM THE IETF MEETING
  6.  
  7.                        March 8th, 1993
  8.  
  9.          Reported by:  Greg Vaudreuil, IESG Secretary
  10.  
  11. This report contains IESG meeting notes, positions and action items.
  12.  
  13. These minutes were compiled by the IETF Secretariat which is supported
  14. by the National Science Foundation under Grant No. NCR 8820945.
  15.  
  16. For more information please contact the IESG Secretary.
  17. iesg-secretary@cnri.reston.va.us.
  18.  
  19.  
  20. ATTENDEES
  21. ---------
  22.  
  23.     Almquist, Philip / Consultant
  24.     Crocker, Dave / SGI
  25.     Crocker, Steve / TIS
  26.     Coya, Steve / CNRI
  27.     Gross, Philip / ANS
  28.     Hinden, Robert / SUN
  29.     Hobby, Russ / UC-DAVIS
  30.     Huizer, Erik / SURFnet
  31.     Knowles, Stev / FTP Software
  32.     Stockman, Bernard / SUNET/NORDUnet
  33.     Vaudreuil, Greg / CNRI
  34.  
  35. IAB Liaison
  36.     Chapin, Lyman / BBN
  37.     Christian Huitema / INRIA
  38.  
  39. Regrets
  40.  
  41.     Borman, David / Cray Research
  42.     Reynolds, Joyce / ISI
  43.     Piscitello, Dave/ Bellcore
  44.  
  45.  
  46. AGENDA
  47. ------
  48. 1) Administrivia
  49.    o Role Call
  50.    o Bash the Agenda
  51.    o Approval of the Minutes
  52.         - February 22, 1993
  53.         - March 8th
  54.  
  55. 2) Protocol Actions
  56.    o Path MTU Discovery <Draft>
  57.    o IESG Advice from Experience with Path 
  58.         MTU Discovery <Informational RFC>
  59.    o RFC 1327 tutorial <informational RFC>
  60.    o IEEE 802.5 Token Ring MIB <Draft>
  61.    o IEEE 802.4 Token Bus MIB <historic>
  62.  
  63. 3) Management Issues
  64.    o Query sent to SNMP Working Group members
  65.    o SNMP Security/v2
  66.    o Router Requirements
  67.    o The US Domain, Farnet, and NWnet
  68.    o MIBs in Waiting
  69.  
  70. 4) Working Group Actions
  71.    o Authorization and Access Control (aac)
  72.  
  73. 5) Tasked Items
  74.    o Summarize the New IP Discussions
  75.    o New IPLPDN charter & milestones
  76.    o Secure FTP
  77.  
  78.  
  79. MINUTES
  80. -------
  81.  
  82. 1) Administriva
  83.  
  84.  o Approval of the Minutes
  85.  
  86.    Discussion and approval of the minutes of both the March 1st and the
  87.    February 22nd teleconferences was deferred.
  88.  
  89.  o Next Meeting
  90.  
  91.    The next IESG teleconference was scheduled for Thursday, March 18th,
  92.    from 11:30 to 1:30 ET.
  93.  
  94. 2) Protocol Actions
  95.  
  96.  o MTU Discovery
  97.  
  98.    The IESG reviewed the MTU Discovery Protocol as documented in
  99.    RFC1191.  This protocol is widely implemented and is in use in the
  100.    operational Internet.  A known operational problem is documented in
  101.    a companion document "IESG Advice from Experience with Path MTU
  102.    Discovery".  The IESG approved this protocol for elevation to Draft
  103.    Standard and the companion document was recommended for publication
  104.    as an Informational RFC.
  105.  
  106. ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
  107. Protocol as a Draft Standard.
  108.  
  109.  o RFC 1327 Tutorial
  110.  
  111.    This document is a tutorial on the X.400 <=> RFC 822 mail gateway.
  112.    Consideration was deferred until the next IESG meeting to review the
  113.    document.
  114.  
  115.  o Token Ring MIB
  116.  
  117.    The IESG discussed the urgency of considering the Token Ring MIB in
  118.    the absence of a Network Management Area Director.  This protocol
  119.    has been a proposed standard for over two years and requires review,
  120.    but there is not strong pressure to elevate it immediately.  The
  121.    IESG agreed to put a review of this protocol on hold pending
  122.    appointment of a new Area Director.
  123.  
  124.  o Token Bus MIB
  125.  
  126.    The IESG agreed that the Token Bus MIB could be moved to Historic
  127.    without having an Network Management Area Director.
  128.  
  129. ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
  130. Bus MIB to Historic.
  131.  
  132.  
  133. 3) Management
  134.  
  135.  o SNMP Working Group Query
  136.  
  137.    Erik Huizer sent out a query to the SNMP Version 2 and SNMP Security
  138.    Working Groups soliciting comments on the process by which these
  139.    proposals were submitted and reviewed.  Specific comments were made
  140.    about the steering group management, the split of security into a
  141.    separate working group, and the compressed timeline, but the
  142.    comments were generally positive and indicated that the current
  143.    process should continue.  A full summary of this query is included
  144.    as an Appendix.
  145.  
  146.    Until the SNMP working groups submit the protocols to the IESG,
  147.    there is no further action for the IESG.
  148.  
  149.  o Working Group Management
  150.  
  151.    Well defined procedures for working groups to follow will help
  152.    answer specific questions about the standardization process.  Erik
  153.    Huizer has posted an initial document with these procedures and will
  154.    incorporate lessons learned from the SNMP Evolution process.
  155.  
  156. ACTION: Huizer - Revise the draft of the Working Group guidelines
  157. document in light of the SNMP Evolution process and incorporating
  158. revisions suggested by Gross and DCrocker.
  159.  
  160.  o US Domain
  161.  
  162.    Issues about the management of the .us domain were taken off the
  163.    agenda and will be discussed within the Operations Area.  It is not
  164.    clear there are issues needing IESG attention.
  165.  
  166.  o Router Requirements
  167.  
  168.    The editor of the Router Requirements documents was contacted and
  169.    gave a brief status update.  The documents are under significant
  170.    revision, including the splitting of the main document into four and
  171.    incorporating changes necessary due to the passing of time.  There
  172.    are a few technical details still to work out and it is not expected
  173.    that this work will be concluded in the next few weeks.  The IESG
  174.    explored options of posting the current documents again as Internet
  175.    Drafts but reached no firm conclusions about whether the documents
  176.    which are almost ready should be posted immediately or whether the
  177.    documents should all be posted as a set.  Discussion will continue
  178.    at the next meeting.
  179.  
  180.  o Many Mibs
  181.  
  182.    There are several MIBs which have been submitted to the IESG for
  183.    consideration as Proposed Standard but for which the Area Director
  184.    review has not been completed.  The IESG agreed that advancing these
  185.    MIBS can be put on hold until a new Network Management Area Director
  186.    is appointed.
  187.  
  188. 4) Working Group Actions
  189.  
  190.  o Authentication and Access Control (aac)
  191.  
  192.    The charter was not received by the IESG and needs to be resent
  193.    before it can be considered.
  194.  
  195. ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
  196. consideration as a Working Group.
  197.  
  198. 5) Tasked Items
  199.  
  200.  o New IP Status Check
  201.  
  202.    The list of New IP contenders has risen to five with the inclusion
  203.    of Robert Ullmann's IPv7 proposal.  The feedback from the IETF
  204.    suggests that the list of contenders should not be artificially
  205.    pruned, but that the proposals be evaluated based on some metric of
  206.    progress.  The immediate question facing the IESG is the allocation
  207.    of presentation time at the March IETF meeting.  Rather than give
  208.    time for open discussion, the IESG agreed that the presentations
  209.    should present specific information on the progress made since the
  210.    last meeting.  This progress would include information such as new
  211.    specifications written, implementations tested, and Internet
  212.    integration and deployment examined.  Dave Crocker notified the IESG
  213.    that the SIP and IPAE Working Groups should now be considered a
  214.    single effort.
  215.  
  216. ACTION: Knowles -- Query each of the New IP contenders for their
  217. current status in anticipation of making presentation time allotments.
  218.  
  219.  o IPLPDN
  220.  
  221.    There is a lively discussion of the IPLPDN Working Group charter.
  222.    The negotiations between the Working Group and the IESG continue
  223.    over limiting the scope of the Charter.
  224.  
  225.  o Secure FTP.
  226.  
  227.     Preliminary inquiries indicate that Common Authentication
  228.     Technology may be the proper technology for securing FTP.  It
  229.     appears that the application of CAT to FTP can be done by the CAT
  230.     Working Group.
  231.  
  232. ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
  233. to explore the incorporation of CAT to FTP.
  234.  
  235.  
  236. Appendix - Summary of Action Items Assigned
  237.  
  238. ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
  239. Protocol as a Draft Standard.
  240.  
  241. ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
  242. Bus MIB to Historic.
  243.  
  244. ACTION: Huizer - Revise the draft of the Working Group guidelines
  245. document in light of the SNMP Evolution process and incorporating
  246. revisions suggested by Gross and DCrocker.
  247.  
  248. ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
  249. consideration as a Working Group.
  250.  
  251. ACTION: Knowles -- Query each of the New IP contenders for their
  252. current status in anticipation of making presentation time allotments.
  253.  
  254. ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
  255. to explore the incorporation of CAT to FTP.
  256.  
  257.  
  258. Appendix - Results of the SNMP Community Survey
  259.  
  260.  
  261.                       IESG report on SNMPv2 Process Inquiry
  262.                                   Erik Huizer
  263.                                  10-March-1993
  264.  
  265.  
  266. Introduction
  267. ------------
  268.  
  269. In the Network Management and Security Area of the IETF, two working
  270. groups have been working hard to define a new and secure version of
  271. SNMP, called SNMPv2. These Working groups are the SNMPv2 Working Group
  272. and the SNMP Security Working Group. These WGs have by early 1993
  273. produced 12 Internet Drafts, which they will soon submit to the IESG
  274. for advancement to proposed standard status. Recently, from a variety
  275. of channels and to more than one member, complaints have reached the
  276. IESG which call into question the process by which SNMPv2 has
  277. advanced. SNMP is too important and the persistence of background
  278. discomfort too significant for the IESG to ignore. Therefore the IESG
  279. found it necessary to establish if the complaints are unfounded or
  280. not, with the intention of putting matters of the WG's process to
  281. rest.
  282.  
  283. To achieve this the IESG through one of its uninvolved members (the
  284. author) held an E-mail inquiry amongst the members of the Working
  285. Groups, asking for their comments on the process followed in the
  286. creation of the SNMPv2 documents.  It must be stated that there have
  287. been no official complaints made to the IESG, and as such this inquiry
  288. is unprecedented, therefore the inquiry included a request for
  289. comments on the inquiry itself.
  290.  
  291. This report summarises the results from the inquiry. 
  292.  
  293.  
  294. The Inquiry 
  295. ----------- 
  296.  
  297. The following text was send by E-mail to the
  298. distribution lists of the two Working Groups on the 2nd March 1993:
  299.  
  300. "The SNMPv2 process is drawing near to a conclusion with the
  301. submission of 12 documents to the IESG. The IESG is working to process
  302. these documents as soon as possible.  
  303.  
  304. Recently, from a variety of channels and to more than one member,
  305. complaints have reached the IESG which call into question the process
  306. by which SNMPv2 has advanced. The entire IETF is accountable for the
  307. standards it produces, and the IESG is obliged to investigate these
  308. complaints to determine whether the process has remained fair and open
  309. throughout. The IESG realizes the importance of a broad acceptance of
  310. SNMPv2 and finds it necessary to establish that the complaints are
  311. unfounded. The IESG has charged me, a non-partisan in the NM area, to
  312. approach the community most directly involved with SNMPv2 for input.
  313.  
  314. Therefore I send you this message, and ask each and everyone of you
  315. who has comments on the process that led to the creation of SNMPv2 to
  316. send me a PERSONAL note. It should present your candid and
  317. confidential assessment of the chronology of events leading to the
  318. request to advance SNMPv2 to proposed standard, from the original call
  319. for contributions through the most recent postings to the mailing
  320. list.  Since it is equally important to the IESG to hear from those
  321. who view the process as having succeeded as not, I urge you to
  322. respond.  Please rest assured that your correspondence will remain
  323. entirely confidential; I will report back to the IESG in a summary
  324. fashion.
  325.  
  326. The IESG does not wish this "process checkpoint" to further delay the
  327. advancement of these standards. You thus have until monday 8 march 9
  328. am EST to react. This will give me enough time to summarise before the
  329. IESG meeting later that day.
  330.  
  331. So if you want to send me a personal note on this subject, do it now,
  332. and make sure that it has the same subject line as above, preceded by
  333. "re:".  
  334.  
  335. I apologise to everyone who feels offended by this note, or by the
  336. query.  The IESG recognizes that requests of this nature are highly
  337. unusual, and deeply regrets having to proceed in this fashion. Indeed,
  338. if you find this action to be contrary to the best interests of the
  339. community, the IESG is interested in this feedback as well. We are
  340. trying to do what is best from the community, and taking the question
  341. to the community seems to be our best alternative in this matter."
  342.  
  343.  
  344.  
  345. The inquiry was aimed at the process followed, and not at he technical
  346. contents of the WGs ofr the documents produced. For comments on the
  347. technical contents of documents the IESG will use the normal "Last
  348. Call" mechanism. Therefore remarks regarding technical contents of the
  349. documents in response to the inquiry have been ignored.
  350.  
  351. The response 
  352. ------------ 
  353.  
  354. The WG on SNMP Security distribution list contained 258 entries at the
  355. moment the inquiry was sent. The SNMPv2 distribution list contained
  356. 459 entries. Only 37 people responded to the inquiry before the
  357. deadline, 27 of them have E-mail addresses that indicate a commercial
  358. background.
  359.  
  360. By far the majority of the people who responded (84%) claimed to be
  361. passive listeners. I.e. they were interested participants, but did not
  362. contribute any new ideas, nor participated actively in discussions on
  363. the WG lists.
  364.  
  365. Although it is impossible to draw a unanimous conclusion from the 37
  366. responses, the following observations are supported by at least 75% of
  367. the responding people:
  368.  
  369. 1- On the whole the process leading to the 12 Internet Drafts has been
  370.   as fair as possible and not much different from other IETF WG
  371.   processes; The current set of documents is cetainly the best that
  372.   could have been produced in such a short time, and is believed to be
  373.   the only one to get the majority consensus from the WGs.
  374.  
  375. 2- There has been too much haste in getting the SNMPv2 proposal out;
  376.   There was no need for the IESG and the Working Groups to set such a
  377.   sharp deadline (december 1992). This deadline, and the pressure it
  378.   created made various contributors feel that their proposals did not
  379.   get the proper attention.  Especially a final WG meeting in March
  380.   (Columbus) would have been a good thing.
  381.  
  382. 3- The WG chairs have acted correctly, and they have done a wonderfull
  383.   job of making sure that the documents were ready on time; All this
  384.   within the limited timeframe, and with little leeway to have lengthy
  385.   discussions on alternative proposals.
  386.  
  387. 4- The authors of the original SMP documents should have been more
  388.   restrained in their reactions; It was suggested that the original
  389.   authors should not have been the editors of the final documents,
  390.   although this clearly would have delayed the WGs. The amount of work
  391.   put in by the authors is very much appreciated and they are generally
  392.   acknowledged as THE authorities with respect to SNMP. However, the
  393.   original SMP authors had too much of a headstart in thinking along the
  394.   proposed SNMPv2 lines. This made them react (too) fast to alternative
  395.   proposals, which thus gave the (false) impression of not being
  396.   considered seriously. The authors also repeatedly used the argument
  397.   that their proposal was supported by working implementations, while
  398.   the alternatives were not. This is not a proper argument to be used in
  399.   a working group when working on a new protocol.
  400.  
  401. 5- The decision to split the work over two Working Groups was
  402.   unfortunate.  The two IESG Area Directors appointed to the process
  403.   were either too involved, or not involved enough. This lead to
  404.   miscommunication between the WGs and the IESG.
  405.  
  406. 6- There was no objection against, but also no real necessity for the 
  407.    IESG to do this inquiry.
  408.  
  409. 7- Due to time pressure the security aspects that have been introduced
  410.   did not get the necessary attention/discussion
  411.  
  412. 8- The concept of a design team going off and preparing an initial
  413.   working document is applauded. However there should be regular
  414.   feedback from a design team into the WGs. The current situation where
  415.   the result of the design team was heralded into the world through
  416.   the press has been found very counter-productive.
  417.  
  418.  
  419. The Conclusions and recommendations
  420. -----------------------------------
  421. The SNMPv2 documents have been produced according to the normal IETF
  422. process with the two involved WGs operating much in the same way as
  423. other Working Groups. If there are any remarks to be made about the
  424. process they can be traced back to two main errors: 
  425. - The IESG has failed to manage the SNMPv2 process properly; The main
  426.   error being that the deadlines put onto the WGs were unnecessary
  427.   tight.  
  428. - The authors of the original SMP proposal have chosen an unfortunate
  429.   way of presenting their proposals 'out of the blue' and defending 
  430.   them.
  431.  
  432. Despite these shortcomings the WG chairs, the authors and other WG
  433. members succeeded in getting the documents ready within the agreed
  434. deadlines. The "Last Call" mechanism will have to show whether there
  435. are still technical issues unresolved that prohibit moving the
  436. documents to Proposed Standard and reviewing the results of this
  437. before moving them to Draft Standard.
  438.  
  439. The inquiry performed by the IESG was usefull although not perceived
  440. to be necessary, and the amount of responses seems to confirm the
  441. latter. The IESG should therefore in future refrain from these kind of
  442. inquiries unless there are official complaints.  
  443.